A Database Management System (DBMS) stores large volumes of data to support diverse workloads and heterogeneous applications. The DBMS is critical to business transaction processing and decision making, and may incorporate strategies that promote keeping the data highly available. However, a DBMS may unexpectedly fail for various reasons, including defects in a hardware or software component within a computer system.
A DBMS may perform many complex operations, consisting of multiple steps, such as for example, creating a new table. The amount of work required to complete an operation varies, and may depend upon such factors as the algorithms and architecture chosen by the DBMS vendor to implement product features. Similarly, the time required to recover an operation (i.e., replay from the log) varies by the type of operation. For example, a table reorganization operation is much more complex, i.e., takes more steps to complete, than an operation to insert a row of data in a table, and consequently will take much longer to recover. A recovery cost is not a simple linear function that is based solely on the amount of data and a number of operations, but is also dependent on the type of workloads and the complexity of the operations that are executed. The nonlinear nature of database operations makes it challenging for a Database Administrator (DBA) to predict the time it will take to perform a future recovery operation. Consequently, the DBA may often rely on a combination of intuition, trial and error, and experience when designing a recovery plan to meet the business enterprise's Recovery Time Objective (RTO), which may be referred to as a maximum length of time that a DBMS may remain unavailable following a service disruption.
One solution that the DBA may often choose is to back up a database more frequently than required, rather than risk a situation where the business may miss the RTO goal or be unable to meet a Service Level Agreement with an end user community. This problem becomes more pronounced in a cloud environment where the volume of data tends to be high, the types of workloads accessing the data tend to be much more diverse, and there tends to be fewer DBAs available to manage the installation. It may also be advantageous, when planning for or monitoring recovery operations, for a DBA or an administrative tool to be able to predict with reasonable accuracy how long a particular recovery will take.
It may therefore be desirable, among other things, to provide a method and system of classifying database operations by their estimated recovery cost, and tracking the number of each kind of operation that has been performed on a database such that the amount of time necessary to complete a recovery operation for the database can be approximated with reasonable accuracy.